Configuration and Use of PPP, "Pipeline", September/October 1995, vol.6, no.5

Pipeline, September/October 1995, vol.6, no.5
Copyright © 1995 Silicon Graphics

Configuration and Use of PPP

PPP (Point to Point Protocol) is a method of connecting a TCP/IP host to another TCP/IP host or network by utilizing a direct communication link between the two hosts. Most often, the method employed is a serial connection over a telephone dial-up circuit using standard modems. This article addresses the setup and operation of PPP over serial connections. It is assumed that the reader is a system administrator familiar with modems and TCP/IP.

SGI's implementation of PPP under IRIX offers the user an enhanced degree of functionality and security over SLIP (Serial Line Internet Protocol). PPP should be selected as the method of choice for serial TCP/IP connectivity if any of the following are a consideration:

user authentication on a session level, using either ordinary UNIX passwords or PAP (Password Authentication Protocol), discussed in detail later in this article.
dynamic as well as static, and local or remote IP addressing
ability to negotiate protocol features with remote host
interoperability between implementations. Because the SLIP specification is not as well defined as PPP, more interoperability issues occur with SLIP than with PPP.

Assumptions

The following assumptions are made in this article:

The system referred to as the PPP server is con- nected to a larger network, such as an Ethernet, or to the Internet in general.
The system referred to as the PPP client is a remote system, which may or may not be connected to any other network. It may serve as a gateway for a small LAN (Local Area Network), but this is not germaine to this discussion.
Both client and server are running IRIX 5.2, IRIX 5.3, or IRIX 6.0.1. This article assumes an IRIX 5.3 environment.
The necessary software subsystems to support PPP have been installed from the IRIX distribution media.
- For IRIX 5.2 and IRIX 6.0.1, the subsystems are:
  - eoe1.sw.ppp
  - eoe2.sw.uucp
  In addition, IRIX 5.2 requires:
  - Patch 84 for IRIX 5.2 (a version of inst(1M) that can install patches)
  - Patch 151 for IRIX 5.2
  SGI does not recommend attempting to run PPP under IRIX 5.2 if these patches are not installed. Customers should contact their support provider for information regarding patch availability. Customers running IRIX 5.2 without access to patches are advised to upgrade to IRIX 5.3 before attempting to run PPP.
- For IRIX 5.3, the subsystems are:
  - eoe2.sw.uucp
  - eoe2.sw.ppp
- The reader of this article is familiar with a text editor such as vi(1) or jot(1). Additionally, the reader must be familiar with UNIX shell scripts since no GUI tool exists for configuring PPP with serial ports.
- The installation and configuration of PPP must be performed by the root user, except where noted otherwise.
- All configuration and operation examples assume the point of view of the client system (i.e., the client system dials out, initiating the connection to the server).
- Examples of modem installation and configuration assume the modem in use to be a U.S. Robotics Sportster modem (either the 14.4k or 28.8k model), and a system serial port rate of 38400 bps (bits per second)

Selecting a Modem

SGI does not recommend or advocate the purchase of any particular brand or type of modem, other than to recommend that a modem supporting the ITU "V" protocols be used rather than a modem supporting proprietary protocols (such as PEP, HST, or early V-series protocols). ITU stands for International Telecommunication Union, and is the organization that drafts and approves telecommunications recommendations. It is the successor to the now-disbanded CCITT (Consultative Committee for International Telegraph and Telephone) organization from which most V protocols originally emerged.

The following modems have predefined configuration scripts (provided for customer convenience only) in the directory /etc/uucp. In addition, an entry for each of these modems is provided in the file /etc/uucp/Dialers.

     Modem			Configuration
				   Script 
----------------------		------------------
Telebit T2500, T1600,		fix-telebit 
QBlazer, T3000, and 
WorldBlazer 

ZyXEL U-1496			fix-zyxel

Intel 14.4ex 			fix-intel

DSI 9624 models 		fix-dsi

US Robotics Sportster 		fix-usr

Hayes ACCURA			fix-hayes
 (also called Hayes14)

Table 1. Available Modem Configuration Scripts

In general, the system should be set to the highest speed common to both the modem and the system. However, as long as flow control is working effectively between the system (DTE or Data Terminal Equipment) and the modem (DCE or Data Communications Equipment,) it is not necessary to have the serial port run at the same speed as the modulation (modem to modem communication) speed. IRIX 5.x and IRIX 6.0.x and most modern modems support 38400 bps serial communications speeds. The DTE rate chosen must be as least as fast as the maximum speed at which the modem can connect to another modem. For a modem with a maximum connect rate of 14.4 kbps, a DTE rate of 19.2 kbps is required. For a modem that can connect as fast as 28.8 kbps, use a DTE rate of 38.4 kbps.

Hardware flow control (also known as RTS/CTS) is used to help prevent data overruns (or data loss).

As IRIX PPP presently cannot utilize software (XON/XOFF) flow control, it must be disabled on the modem in favor of hardware flow control. Most modern modems implement hardware flow control in their factory default configuration. If, for any reason, the modem is configured to accept software flow control, there is an extremely good probability that PPP will not operate due to packet data loss.

Selecting a Cable

SGI recommends against using any serial cable not specifically built or sold for an SGI system. The pin configuration for the SGI serial ports is not compatible with that of Personal Computers or Apple Macintosh systems. Any serial cable obtained must support full hardware (RTS/CTS) flow control as well as modem (DCD/DTR) control. SGI can supply a DIN-8 to 25 pin modem cable, model number X5-25TO8 (part number 018-8109-001). For systems with a 9 pin connector (Power series, Crimson, CHALLENGE, and Onyx,) a custom cable that supports the unique SGI serial pinouts must be made or obtained from a third party vendor.

Complete pinout information is available in the serial(7) manual page. When reading the manual page, remember that all diagrams refer to the view of the socket at the back of the system. Most cable problems can be traced to interpreting the diagrams incorrectly.

Additional information on SGI serial ports can be found in the article titled "Serially Connecting a Personal Computer to an IRIS" in the September/October 1994 issue of Pipeline (available on-line with InSight(1) if Support Advantage is loaded).

Selecting a Port

A serial communications port must be selected on each client and server system. The ports chosen on the two systems can have different port numbers. This article uses port two on the client and port three on the server. Use the command hinv(1) to help determine the ports that are available.

In general, use of port one should be discouraged. On a non-graphic system, port one is used as the console and it is not available for PPP. On a graphics system, port one is the alternate console port (often used for debugging). If port one must be used on a graphics system, its potential use as the alternate console port must be disabled. To disable port one as the alternate console port, edit the file /etc/inittab and change:

t1:23:respawn:/sbin/getty ttyd1 co_9600 # alt console

to:

t1:23:off:/sbin/getty ttyd1 co_9600 # alt console

To make this change take effect, use the following command:

# telinit q

Smaller SGI systems have two serial ports (four on the 4D/30 and 4D/35.) Larger systems generally have more than two serial ports and more can be added. Note that port four on a CHALLENGE (L or XL) or Onyx system is an RS-422 port and cannot be configured for PPP.

Configuration of the PPP Client

This section describes the steps that must be completed on the client. This section assumes that the hostname, domain, and IP address of the client have been set using the Network Setup icon under Desktop/System Manager.

Modem Configuration

Using a cable either purchased from SGI or made specifically for a SGI system, connect the modem to the serial port on the system. Then, program the modem with the following command:

# /etc/uucp/fix-usr -o -m SPORT -s 38400 2

This operation normally needs to be run only once (unless the modem is reconfigured by some other application). If there is no fix- script available for the modem, it must be initialized to suitable settings by other means. While configuration varies widely among modems, the fix-hayes script should provide information on the necessary steps.

Requests for assistance in configuring the modem should be referred to the modem supplier, and not to SGI.

System Configuration

There are several files that need to be configured on the client. The following sections provide details on how to accomplish this. Note that it is necessary for the system administrator to substitute appropriate hostnames, domains, and IP addresses for both the client and server.

/etc/inittab

Make sure that the entry in the file /etc/inittab for port two is turned off.

t2:23:off:/etc/getty -N ttyd2 co_9600 # port 2

Note that since the port is turned off, neither the baud rate nor device name must match exactly.

After the port has been configured, use the following command to make this change take effect:

# /etc/telinit q

/etc/uucp/Devices

SGI recommends that all additions and changes be made at the end of the file to simplify future updates. Make sure that any unwanted entries are commented out (using the # character at the beginning of the line.) The following entry defines a direct port to allow debugging of the modem, if necessary.

Direct ttyd2 - Any direct

Entries for PPP also need to be added. The file entries are based upon the modem type. If there is more than one modem on the client and all modems are "equivalent" (any modem can connect to any destination,) then use the same label for each modem (ACUppp); otherwise make different labels for each class of modem. Make sure that the last field (usr in this example) is found in the file /etc/uucp/Dialers, or connections to the modem will fail.

ACUppp ttyf2 null 38400 212 x usr

/etc/uucp/Dialers

Typically, no changes are needed to this file. The only exception is for a pulse-dial telephone system. For a pulse-dial system, change the string ATdt to ATdp (the example has a line break for legibility).

usr =W-, "" \dATs0=0\r\c OK\r-\rATs0=0\r\c-OK\r 
	ATdt\T\r\c CONNECT

/etc/uucp/Systems

The file /etc/uucp/Systems contains information for dialing the modem and logging into the server (to start PPP). As in the Devices file, all entries should be added to the end of the file. Each entry must be made on a single line (the example has a line break for legibility.) Note that the space before pppcli is required. Although not required, the server system name in this file typically matches the hostname defined in the file /etc/hosts.

pppserv Any ACUppp 38400 phone_number ""\r\c ogin: 
	pppcli assword: ppp-pass PPP

Because IRIX sends out a message with the framing name (PPP) before actually starting the protocol, adding a final match of PPP ensures that the login actually succeeded.

/etc/hosts

A minimum of three entries is required in this file. If DNS (Domain Name Service) is used on the Ethernet LAN, other entries may be obtained from the nameserver after a connection is made. If DNS is not used, each host that the client will connect to should have an entry in the client's /etc/hosts file. For example, a minimal /etc/hosts file could have contents similar to the following. For more information on the file /etc/hosts, refer to the manual page for hosts(4).

127.0.0.1 localhost loghost 
192.0.2.2 pppserv.domain.com pppserv 
192.0.2.3 pppcli.domain.com pppcli

/etc/ppp.conf

The file /etc/ppp.conf should contain an entry to identify the server system to the client's PPP process. If the name of the PPP server is defined in the file /etc/uucp/Systems and the hostname and IP address of the PPP server are defined in /etc/hosts, no entry needs to exist at all for the server system. Default values are assumed by the client PPP process. However, SGI does recommend that an entry similar to the following appear in the file /etc/ppp.conf on the client for reference purposes. (This entry is the default assumed by PPP if no entry exists in the file /etc/ppp.conf to identify the PPP server.) Special features, such as dynamic address assignment, require an entry for the server in the file /etc/ppp.conf.

pppserv out remotehost=pppserv.domain.com

Note that this entry is fairly minimal. There are many options that can be specified in the file /etc/ppp.conf. Refer to the section titled "Configuring /etc/ppp.conf" or the manual page for ppp(1M) for more information.

Configuration of the PPP Server

This section describes the steps that must be completed on the server. This section assumes that the hostname, domain, and IP address of the server have been set using the Network Setup icon under Desktop/System Manager.

Modem Configuration

Using a cable either purchased from SGI, or made specifically for a SGI system, connect the modem to port three on the system. Then, program the modem with the following command:

# /etc/uucp/fix-usr -i -m SPORT -s 38400 3

This operation normally needs to be run only once (unless the modem is reconfigured by some other application.) If there is no fix- script available for the modem, it must be initialized to suitable settings by other means. While configuration varies widely between modems, the fix-hayes script should provide information on the necessary steps.

System Configuration

There are several files that need to be configured on the server. The following sections provide details on how to accomplish this. Note that it is necessary for the system administrator to substitute appropriate hostnames, domains, and IP addresses for both the client and server.

/etc/passwd

Each PPP client should have an entry in the file /etc/passwd. Typically the hostname of the client is used as the login user name on the server. Also, ensure that the client account runs with root privileges.

pppcli::0:0:PPP login pppcli.domain.com,,:/:/usr/etc/startppp

Root should set a password for the account as soon as it is created and this password should match the one defined in the file /etc/uucp/Systems on the client.

# passwd pppcli

Changing password for pppcli on pppserv.

New password:<ppp-pass> Re-enter new password:<ppp-pass>

/usr/etc/startppp

The file that is referenced at the end of the /etc/passwd entry for the client pppcli is simply a shell to invoke PPP upon login. This file can have virtually any name, and need contain only these minimal lines:

#!/bin/sh 
exec /usr/etc/ppp -r pppcli 

/etc/inittab

The file /etc/inittab must be modified to enable dial-in access on the selected port (port three in this example). Edit the file and change this line:

t3:23:off:/etc/getty -N ttyd3 co_9600 # port 3

to a line similar to this:

t3:23:respawn:/usr/lib/uucp/uugetty -Nt60 \
	-iusrin,conn ttyf3 dx_38400

For information on the options available to uugetty(1M), refer to the manual page for uugetty(1M). The option -iusrin,conn defines the modem as a US Robotics (usr) for dial-in access. Similar entries are available for other modem types (refer to the file /etc/uucp/Dialers for a list). Use the same speed in every configuration step for a given port. After the port has been configured, use the following command to make this change take effect:

# /etc/telinit q

/etc/uucp/Devices

While the information in this file is generally only necessary for outbound dialing, it is a good idea to ensure that the device entries on the server are properly configured. Refer to the section titled "/etc/uucp/Devices" under "Configuration of the PPP Client" for more information.

/etc/hosts

The file /etc/hosts should contain at least the minimum set of hosts as described for the client system.

127.0.0.1 localhost loghost 
192.0.2.2 pppserv.domain.com pppserv 
192.0.2.3 pppcli.domain.com pppcli

Unlike the client configuration notes, SGI recommends that the server not rely upon dynamic addressing for the client. The server should have known addresses for the client as well as itself. Refer to the section titled "Configuring /etc/ppp.conf" for details on using localhost and remotehost to enable dynamic addressing.

/etc/ppp.conf

The file /etc/ppp.conf should contain an entry to identify the client system to the server's PPP process. The following is a very minimal entry to identify the client system, and does not take into account issues such as authentication, dynamic addressing, or special features. Refer to the section titled "Configuring /etc/ppp.conf" or the manual page for ppp(1M) for more information.

	pppserv out remotehost=pppserv.domain.com

Hostname resolution

Hosts on an IP network use unique address numbers to identify each other and are usually also assigned a hostname. The process of mapping between names and addresses is called hostname resolution. On an SGI system, there are three standard ways to perform hostname resolution "NIS", "DNS", and "local".

NIS (Network Information Service, previously known as YP or Yellow Pages) allows centralized maintenance of many maps, including hostnames and addresses on one or more servers within a domain.
DNS (Domain Name Service), also known as "bind" (Berkeley Internet Name Daemon) allows maintenance of hostnames and addresses on multiple domains and subdomains using co-operating daemon processes on multiple servers.
Local resolution keeps all information on each system in the file /etc/hosts.

The order of name resolution defaults first to "nis", then to "bind" and then "local" on an SGI system. This order may be changed in the file /etc/resolv.conf. Because a PPP client has no access to the net until the PPP connection is running, a minimal /etc/hosts file must be created and must include the PPP client, PPP server, and localhost (i.e., loopback) names and IP addresses.

One strategy that minimizes use of network bandwidth is to add frequently accessed hosts to the local /etc/hosts file, and specify a resolution order of "local" and then "bind". Essentially, any hostname resolution method will work, provided the PPP link is functioning properly.

# resolv.conf for PPP client
# PPP server is 192.0.2.2, use that as primary
# nameserver
domain sub.comain
nameserver 192.0.2.2
hostresorder local bind

Figure 1. Sample resolv.conf file

Routing

Generally, a client connected via PPP to a server needs to set up a default route to direct all outbound network data to the server. This can be done via an add_route option in the server's host entry in /etc/ppp.conf. By specifying an appropriate route(1M) command, this option may also be used to generate specific host or network routes via the PPP server connection. Refer to the section titled "Configuring /etc/ppp.conf" for examples.

Routing can be an extremely complex issue. Most routing issues can be avoiding by assigning the client an address within the same IP network as the server and having the server provide proxy ARP for this client. Proxy ARP is a mechanism whereby one host acts as a proxy by accepting packets destined for another physical address as well as its own. (Refer to the manual page for arp(1M) for more information.) One way to configure proxy ARP on the server is to enable it in the shell file that is assigned as the client's login shell on the server. Then establish a default route to the server via the add_route option in the file /etc/ppp.conf on the client system. The following is a sample login shell (/usr/etc/startppp) on the server for a client that implements proxy ARP:

#!/bin/sh 
# /usr/etc/startppp 
/usr/etc/arp -s arp -s pppcli.domain.com \
	 `/usr/etc/netstat -ian | grep :` pub 
exec /usr/etc/ppp -r pppcli $*

In the above example the character ` (back quote) is used and should not be confused with the apostrophe character '. This example assumes the server has a single network interface. If the server has multiple interfaces, the Ethernet address must be manually entered. Refer to the manual pages for arp(1M) and netstat(1) for more information.

Tuning and Configuration Issues

Configuration Flags

To improve performance of the PPP connection, set the following chkconfig(1M) options on the PPP client. While all of the networking functions listed below will work, each requires bandwidth on the PPP connection. Over-use of network daemons may severely impact performance on slower speed PPP links. Be sure to enable network services only if necessary and when the PPP link speed is adequate for the job.

automount 		on	(leave off if no NFS links are needed)
directoryserver		off 
fontserver		off
gated			off 
glb			off 
llb			off 
mrouted 		off 
named 			off 
network 		off 
nfs			on	(leave off if no NFS links are needed)
routed 			off 	(leave on if default route is NOT used)
rwhod			off 
snmpd			off 
timed			off 
yp			off

Kernel Configuration

Decreasing the TCP window space has the effect of improving throughput on slower serial-based links. To decrease the TCP window space, execute the following steps.

Edit /var/sysgen/master.d/bsd using vi or jot, and locate the following parameters:

	/* TCP window sizes/socket space reservation */ 
	/* must be < 512K */
	unsigned long tcp_sendspace = 60 * 1024; 
	/* must be < 512K */
	unsigned long tcp_recvspace = 60 * 1024;

Change the value 60 * 1024 to 4 * 1024:

	/* TCP window sizes/socket space reservation */ 
	/* must be < 512K */ 
	unsigned long tcp_sendspace = 4 * 1024; 
	/* must be < 512K */
	unsigned long tcp_recvspace = 4 * 1024;

Reconfigure the kernel and reboot the system:
```
	# /etc/autoconfig -f 
	# reboot
```

Boot-time Startup Scripts

In certain situations a procedure or daemon needs to be started when the system boots. These situations include adding routes, starting demand dialing PPP, or setting up proxy ARP on a server. This can be accomplished by adding a script to the directory /etc/init.d (the directory in which the system startup scripts are located). Symbolic links should also be created in the directory /etc/rc2.d and /etc/rc0.d to start and stop the script in the correct sequence during bootup and shutdown. A sample startup script for demand dialing PPP and proxy ARP on a server at boot time is provided below. If no other systems are connected locally to this host, proxy ARP is unnecessary and all lines in Figure 2 containing the ARP keyword should be commented out.

----------------------------------------------------------------------
#!/bin/sh
# /etc/init.d/network.local sample file
# to start just after networking, use following commands
# to create auto start  and stop links
# ln -s ../init.d/network.local /etc/rc2.d/S31netlocal
# ln -s ../init.d/network.local /etc/rc0.d/K39netlocal
# starting up local networking stuff
#
# Variable SERVER should only be defined for the server, it is used
# to determine whether client or server commands should be run.
SERVER=/bin/true
case "$1" in
        'start')
                # start up PPP
                /etc/killall -TERM ppp
                if $SERVER; then
                        # set up proxy ARP for the dial-in hosts
                        # if this host has more than one interface,
                        # you will need to hard-code the ethernet MAC address
                        # instead of letting it be determined at run time.
                        # note that 4DDN (among others) may change the
                        # MAC address from default!
                        arp -s client `netstat -ian | grep :` pub
                        arp -s client2 `netstat -ian | grep :` pub
                        arp -s client3 `netstat -ian | grep :` pub
                else
                         /usr/etc/ppp -r remote &
                fi
                ;;
        'stop')
                /etc/killall -TERM ppp
                # be nice and delete the ARP entries
                if $SERVER; then
                        arp -d client
                        arp -d client2
                        arp -d client3
                fi
                ;;
        *)
                echo "usage: $0 {start|stop}"
                ;;
esac
exit 0
----------------------------------------------------------------------------
Figure 2. A Sample network.local Startup File

Configuring /etc/ppp.conf

Parameters specified in a configuration file control PPP session options. The default name for this file is /etc/ppp.conf. An alternate configuration file can be specified by using the -f command line parameter when PPP is started.

This section does not attempt to explain all PPP options. Instead, it briefly discusses some of the more common options. Refer to the manual page ppp(1M) for a complete discussion of configuration options.

The file /etc/ppp.conf file is usually needed on both the client and server.

The discussion that follows uses the following sample /etc/ppp.conf file for a remote system.

pppserv out 
	debug=1 
	add_route=- 
	localhost=0,0 
	remotehost=0,0 
	send_username=pppcli 
	send_passwd=itsme

out     Tells PPP that the local system is expected to call this host
	to establish the session.

debug=x  If debugging is desired on the session, x equals the debug
	level desired, with x being equivalent to the number of
	instances of -d on a command-line specification. A debug
	level of 6 is the maximum.

add_route  This tells PPP to issue a route(1M) command for this
	connection. The data following the equal (=) sign is either a
	minus sign or a text string enclosed in quotes. The minus
	sign is equivalent to adding a default route to this host.
	Specific route commands need to be enclosed in quotes. For
	example:

	add_route="host 192.68.1.20 pppserv 1"

	adds the route for this IP address to pppserv. 
	And:

	add_route=- 

	is equivalent to the option add_route="default pppserv 1"

Consult the manual page for route(1M) for details on issuing route commands.

localhost  Used to assign the IP address and netmask the local system
	will use during the PPP session. If this is set to a value of
	localhost=0,0, the local system is requesting a dynamically
	assigned IP address and netmask from the remote host (usually
	a PPP server).  If localhost is missing from the local
	/etc/ppp.conf, the default IP address and  netmask (as found
	in /etc/hosts and /etc/config/ifconfig-1.options) is used for
	the  session. If a different address and netmask  are
	desired, they are specified as localhost=ipname[,netmask]:

	localhost=192.68.1.20,255.255.255.0

	In this manner, addressing can be either static or dynamic,
	based upon the needs of the client and server system
	administrators.

remotehost  Used to identify the remote system IP address and netmask
	to the local system. If missing, the default IP address for
	the remote hostname (as found in /etc/hosts) will be used, as
	will a default netmask. If the remote hostname is not found
	in the local /etc/hosts file, remotehost=0,0 is assumed and
	the remote system will present its own address and netmask
	during session negotiation.

	This enables the client to accept dynamic addressing for the
	remote system. It is often used in configurations where the
	client calls into a pool of remote servers, and has no way of
	know- ing which server will be used for a specific PPP
	session.

send_username  The user name that is sent for PAP authentication to
	the remote system. It must be both a valid login user name
	and expected via a corresponding recv_username parameter in
	the remote system's /etc/ppp.conf file for this system. This
	is an optional parameter, and is only used if additional
	security is desired.  Exercise caution in combining debugging
	levels higher than 1 with PAP authentication, as the user ID
	and password sent will be logged in clear text in the debug
	log.

send_passwd  The login password for the user ID used above. It must
	be a valid login password on the remote system. This is an
	optional parameter, and follows the same reasons and caveats
	as send_username above.

Security Under PPP

Dialup Passwords

As soon as a modem is connected to a system for dial-in (as it is on the server), the system is exposed to the possibility of security breaches over the telephone network. This document does not attempt to address this topic in detail, but a few simple checks are described here.

The home directory for a PPP account should only be writable by root.

All accounts must be password protected on dial-in systems. Unused accounts must be disabled by placing an * in the second field of the file /etc/passwd or by using the command passwd -l <user-name>. Accounts in this category include: sysadm, diag, daemon, bin, uucp, sys, adm, lp, nuucp, auditor, dbadmin, rfindd, tutor, tour, demos, 4Dgifts, nobody, noaccess, EZsetup, and OutOfBox. Active accounts that need good passwords include: root, guest, and all user accounts. The guest account can still be open to the internal network and yet secure from dial- up by creating a .rhosts file, as follows:

# echo "+ +" >~guest/.rhosts 
# chown root.sys ~guest/.rhosts
# chmod 640 ~guest/.rhosts 
# chown root.guest ~guest/. 
# chmod a+t,g+w ~guest/.

NIS accounts (accounts that start with a + in /etc/passwd) are as important to check as the local ones. In addition, these accounts may be harder to secure. One way of ensuring that all PPP users have a password is by using the option MANDPASS=YES in the file /etc/default/login (refer to the manual page for login(1) for more information). If there is a /.rhosts file, it is mandatory that it be minimal and secure.

# chown root.sys /.rhosts
# chmod 400 /.rhosts

Creating /etc/dialups and /etc/d_passwd Files

To help prevent unauthorized access by outsiders to the internal network, enable the dial-up password facility (Refer to the section on "System Security" in the IRIX Advanced Site and Server Administration Guide, available on-line with InSight.) This is done by creating the files /etc/dialups and /etc/d_passwd. The following example allows PPP connections, but not UUCP or interactive dial-ups on ports two and three.

Create the file /etc/dialups with entries for every modem or terminal line:

/dev/ttyd1
/dev/ttym1 
/dev/ttyf1 
/dev/ttyd2 
/dev/ttym2 
/dev/ttyf2 
/dev/ttyd3 
/dev/ttym3 
/dev/ttyf3

Note that all tty's that have a modem on them must be listed in order for the system to be secure.

Create an /etc/d_passwd file with the following entries:

/bin/csh:*: 
/usr/bin/tcsh:*: 
/bin/sh:*: 
/bin/ksh:*: 
/usr/lib/uucp/uucico:*: 
/usr/etc/remoteppp:: 
/usr/etc/ppp::

Make sure the pathnames for all shells listed in /etc/d_passwd are correct, real paths to the executable. They must not be symbolic links to the real path.

To add encrypted passwords, choose a login account, temporarily change its password, and cut and paste the encrypted password from that login account's entry in /etc/passwd to the corresponding place in /etc/d_passwd. If desired, the dialup password may be unique for each login shell that is being used.

For example, if the password for guest was changed, the entry in /etc/passwd for guest might look like this:

guest:AbZ/.GExn2FAk:998:998:Guest:/usr/people/guest:/bin/csh

The string AbZ/.GExn2FAk would be inserted into /etc/d_passwd for the shells used for PPP. (Remember to return the account "borrowed" for this purpose back to its original password.)

/usr/etc/remoteppp:AbZ/.GExn2FAk: 
/usr/etc/ppp:AbZ/.GExn2FAk:

PAP Password Authentication

PPP implements a method of authentication on a session level called Password Authentication Protocol (PAP). PAP utilizes a simple user name and password pair exchange for authentication. After the initial link is established between a server and a client, the client repeatedly sends the user name and password information to the server until either authentication is acknowledged or the connection is terminated. The user name and password used in PAP authentication are specified in the file /etc/ppp.conf. For this reason, the file /etc/ppp.conf should only be readable by an account with root access. The sections below describe the options in the file /etc/ppp.conf for PAP authentication.

On the Server

recv_username=username  This sets the user name the client must
	present to the server during a PAP exchange. It must be a
	valid IRIX user account found in /etc/passwd. (Only the user
	ID and password fields in /etc/passwd are used for
	authentication. The UID, GUID, shell and other parameters
	associated with the user name are ignored.) More than one
	recv_username entry may exist for a single client entry in
	the file /etc/ppp.conf. This permits the client to use
	several different user names for authentication.

On the Client

send_username=username  This is the user name that is sent to the
	server for PAP authentication.

send_passwd=string  This is the password sent to the server for PAP
	authentication. Once again, it is important to stress that
	/etc/ppp.conf should be readable only by root in order to
	protect the password contained in this entry.

Executing PPP

Since most link or session specific options are controlled via the /etc/ppp.conf file, PPP has few command-line options. A PPP session from the client to the server may be started by executing the following command (as root):

# /usr/etc/ppp -r pppserv

All options for the above PPP session are obtained via the entry for system pppserv in /etc/ppp.conf

Limited command line options are available:

-d      Adding one or more instances of -d to the command line
	increases the amount of debugging information sent to
	standard output (if a tty), or /var/adm/SYSLOG.

	Unless a specific need exists to use debugging, SGI
	recommends not using any instances of -d except when actively
	debugging a PPP connection. One reason to avoid casual use of
	debugging is that levels of debugging above one turns on
	messages from the IRIX kernel.  While the kernel displays the
	message, it has all interrupts turned off. This can cause
	input to be lost, which in turn often causes more messages
	from the kernel, and so on.

-f [cfile]  This parameter tells PPP to reference a file other than
	the default of /etc/ppp.conf for configuration information.

Debugging PPP

IP over serial lines involves a lot of independent pieces; the computers and their software, phone lines, modems, and cables. When problems occur, they can be difficult to isolate.

It is a good idea to start with the basics in any troubleshooting or debugging situation.

Testing the Hardware

Most modems are configured so that it is possible to hear them as they dial. If it is not possible to hear the modem dialing, then there may be a fundamental configuration problem. Check that the modem is configured so it can be heard as it dials.

Check all aspects of the hardware. Make sure that the modem is plugged in, turned on, and the modem cable is securely connected to both the computer and modem. Double check that the cable is plugged into the same serial port that the software was configured for. Don't set up the software to use port two and then plug the modem cable into port one on the back of the computer. Ensure that the modem cable is plugged into the correct jack on the modem. Most modems have two phone jacks on the back. One (usually labeled line or wall) should be connected to the wall jack while and the other (usually labeled phone) can be used to plug a telephone into the same phone line. Plug a phone into the second jack on the modem, if it has one (otherwise in place of the modem), and try dialing the phone number the modem is supposed to dial. If the remote modem does not pick up the phone, then either the number is incorrect, there is a problem with the phone line, or the modem isn't set up correctly on the remote end.

Testing Access to the Modem

If there are entries in the file /etc/uucp/Devices to allow direct access to the modem, it is possible to test that the modem and the system can communicate by using the command (assuming the modem is on port two):

# cu -d -lttyd2

The message Connected should appear on the screen. If it does not, review the debug messages that print out to identify exactly where the connection failed. (The initial debug messages are in the same format as those in the PPP debug session below.) If the Connected message does appear, enter AT. A response of OK should appear. If OK is not displayed on the screen, then the modem is not correctly configured, or there is a problem with the cable.

Checking Configuration Files

Be sure that the baud rate is the same everywhere. Specifically, check the files /etc/uucp/Devices and /etc/uucp/Systems. Verify that the same baud rate was specified to the fix- configuration script. Modems are configured to use a fixed speed and most will not communicate at a different speed.

Using Debug Mode

Debug mode in PPP is enabled by adding one or more instances of -d to the command line, or by adding a debug=x parameter to the file /etc/ppp.conf. Debug output is sent to standard output if the PPP command is entered from a tty device, or to /var/adm/SYSLOG.

When debugging, make sure that the computer is actually communicating with the modem. One of the debugging lines displayed indicates which port the software is trying to use, the speed it is using, and what dialer script it is trying to use. These should match the PPP configuration.

If everything has checked out to this point, the typical problem is a chat script error. Figure 3 provides a complete successful session using PPP between two IRIS systems, as recorded on the client end (pppcli). Comments are enclosed in braces {}.

After the chat script is complete, PPP negotiation takes over. Negotiation consists of a number of requests sent between the server and client, with the requested parameters either acknowledged or rejected. Generally, the less complex the entry is for a remote system in the file /etc/ppp.conf, the less the chance of errors in feature negotiation. Figure 4 continues the trace presented in Figure 3 from the point of session negotiation as recorded on the client (pppcli). Comments are enclosed in braces {}. The following options in /etc/ppp.conf on the client were used for this session:

Client /etc/ppp.conf:

	pppserv out 
	emotehost=0,0 
	localhost=0,0 
	send_username=guest 
	send_passwd=secret

----------------------------------------------------------------------
root@pppcli[121] /usr/etc/ppp -dddddd -r pppserv
pppserv: only the first 7 bytes of pppserv are significant as a UUCP name
pppserv: debug=6 mode=out mindevs=1,out=1,max=4 active_timeout=0,inactive=0
ppp[15708]: pppserv LCP1: initialized   {PPP protocols are initialized}
ppp[15708]: pppserv IPCP1: initialized
ppp[15708]: pppserv CCP1: initialized
ppp[15708]: conn(pppserv)               {The name in the Systems file }
ppp[15708]: Device Type ACUppp wanted   {Device type from
                                        /etc/uucp/Systems entry}
ppp[15708]: Internal caller type 212
ppp[15708]: Use Port /dev/ttyf2, acu - /dev/null, Phone Number x<
                                                {the port
                                                number in use is
                                                ttyf2}
ppp[15708]: /dev/null is open
ppp[15708]: filelock: ok
ppp[15708]: filelock: ok
ppp[15708]: dcf is 7
ppp[15708]: fixline(7, 38400)           {the speed in use }
ppp[15708]: ACU write ok(null)
ppp[15708]: fixline(7, 38400)
ppp[15708]: set interface 212
ppp[15708]: processdev: calling setdevcfg(, ACUppp)   {the Devices entry used }
ppp[15708]: gdial(usrppp) called        {dialer entry from /etc/uucp/Dialers}
ppp[15708]: expect: ("")
ppp[15708]: got it
ppp[15708]: sendthem (<DELAY><NO CR>AT&K0s0=0^M)        {begin modem
                                                        chat script}
ppp[15708]: expect: (OK^M) ppp[15708]: AT&K0s0=0^M^M^JOK^Mgot it
ppp[15708]: sendthem (<NO CR>ATdt95551212^M)    {PPP dials the system}
ppp[15708]: expect: (CONNECT)           {finished dialing, wait for connect}
ppp[15708]: ^JATdt95551212^M^M^JCONNECTgot it           {connected}
ppp[15708]: getto ret 7
ppp[15708]: expect: ("")
ppp[15708]: got it
ppp[15708]: sendthem (<NO CR>@^M)
ppp[15708]: expect: (ogin:)                     {awaiting login prompt}
ppp[15708]: 14400/ARQ^M^J^M^J^J^M
For official use only.^J^M^J^M
Violators will be prosecuted.^J^M^J^M^M^J^J pppserv login:got it
ppp[15708]: sendthem (pppcli^M) {Sends login name from /etc/uucp/Systems}
ppp[15708]: expect: (ssword:)
ppp[15708]: pppcli^M^JPassword:got it
ppp[15708]: sendthem (ppp-pass^M)                       {sends password}
ppp[15708]: expect: (ssword:)
ppp[15708]: ^M^JDialup Password:got it
ppp[15708]: sendthem (d1alpass^M)               {sends dialup password}
ppp[15708]: expect: (PPP)               {awaiting framing message from PPP }
ppp[15708]: ^M^JIRIX Release 5.3 IP7 pppserv^M^J Copyright 1987-1994   Silicon
Graphics, Inc. All Rights Reserved.^M^J Last login: Thu Jul 20 17:55:52 PDT 1995on ttyf2^M^J starting PPPgot it
----------------------------------------------------------------------
Figure 3. Successful PPP Login Between Two IRIS Systems

Server /etc/ppp.conf:

	pppcli in 
	remotehost=pppcli 
	recv_username=guest

Given the above /etc/ppp.conf configurations for both the client and server, the client will request an IP address from the server for both itself and the server. The server will use the address defined in /etc/hosts for the client system, and will provide its own IP address.

Since recv_username is defined in the file /etc/ppp.conf for the server, PAP authentication will be used. The client sends the server a user name of guest and a password of secret. The server will validate the account and password by comparing the user name and password supplied by the client with the information in the file /etc/passwd on the server. If either the user name or password is missing or incorrect, the PAP authentication validation will fail.

In the event of a failed session, the debug trace data can be examined for the area in which the session setup failed. In some instances, an error message is printed indicating an error (in this case of a failed PAP authentication):

ppp[16529]: pppserv PAP1: pppserv does not like our password, \
	 saying "wrong"

In other cases, if the remote system does not understand a particular feature, a repetitive loop of one system sending the same request over and over can be seen until the requesting system times out. The offending request can be examined and corrected on either host at that point.

If the debug trace shows that PPP is running, but there are still problems connecting to remote hosts, it is unlikely that the problem is within the PPP protocol itself. The ping(1M) command may provide more information on where the problem lies. A basic check of network connectivity should be run on the client using the following command:

# /usr/etc/ping -r <IP address of PPP server>

The -r option tells ping to bypass the routing tables. Specifying the IP address bypasses the hostname resolution process. If this command is successful, try removing the -r option to determine if the problem is in routing or in name resolution. For more information on troubleshooting, refer to the section "Setting Up a Network" in the IRIX Advanced Site and Server Administration Guide available on-line with InSight).

-------------------------------------------------------------------
ppp[15708]: pppserv: starting to use /dev/ttyf2
ppp[15708]: pppserv IPCP1: event Open
ppp[15708]: pppserv IPCP1: action TLS
ppp[15708]: pppserv LCP1: event Open
ppp[15708]: pppserv LCP1: action TLS
ppp[15708]: pppserv LCP1: set kernel LCP parameters
ppp[15708]: pppserv 1: entering Establish Phase
ppp[15708]: pppserv LCP1: Initial(0)->Starting(1)
ppp[15708]: pppserv LCP1: event Up
ppp[15708]: pppserv LCP1: send Configure-Request ID=0x38
ppp[15708]: pppserv LCP1: request MRU=1500
ppp[15708]: pppserv LCP1: request ACCM=0x00000000
ppp[15708]: pppserv LCP1: request my magic=0x6907bd47
ppp[15708]: pppserv LCP1: request protocol compression  {default values are sent}
ppp[15708]: pppserv LCP1: request address field compression
ppp[15708]: pppserv 1: write 0x18 bytes: proto=0xc021 01 . . .
ppp[15708]: pppserv LCP1: Starting(1)->Req-Sent(6)
ppp[15708]: pppserv IPCP1: Initial(0)->Starting(1)
ppp[15708]: pppserv: salvaged input packet
ppp[15708]: pppserv: read 0x1c bytes: proto=0xc021 . . .
ppp[15708]: pppserv LCP1: received Configure-Request ID=0x7c
ppp[15708]: pppserv LCP1: accept MTU=1500 request and use MTU=1500
ppp[15708]: pppserv LCP1: note PAP authentication  {PAP req has been
                                                   acknowledged}
ppp[15708]: pppserv LCP1: accept peer's transmit ACCM=0x00000000
ppp[15708]: pppserv LCP1: accept protocol compression
ppp[15708]: pppserv LCP1: accept address field compression
ppp[15708]: pppserv LCP1: event RCR+
ppp[15708]: pppserv LCP1: send Configure-ACK ID=0x7c
ppp[15708]: pppserv 1: write 0x1c bytes: proto=0xc021 02 . . .
ppp[15708]: pppserv 1: raw bytes: 7e . . .
ppp[15708]: pppserv LCP1: Req-Sent(6)->Ack-Sent(8)
ppp[15708]: pppserv: read 0x18 bytes: proto=0xc021 . . .
ppp[15708]: pppserv LCP1: received Configure-ACK ID=0x38
ppp[15708]: pppserv LCP1: event RCA
ppp[15708]: pppserv LCP1: action TLU
ppp[15708]: pppserv LCP1: MTU=1500 MRU=1500 bigxmit=0 TOS=y qmax=50
pcomp=y acomp=y
ppp[15708]: pppserv LCP1: my magic=0x6907bd47,his=0x792ee3e tx_accm=0x0
rx_accm=0x0
ppp[15708]: pppserv LCP1: set kernel LCP parameters
ppp[15708]: pppserv 1: entering Authenticate Phase     {Basic setup complete, do
                                                        authorization now}
ppp[15708]: pppserv PAP1: send request ID=0x4b
ppp[15708]: pppserv 1: write 0x15 bytes: proto=0xc023 01 4b 00 15 08 "guest" 07
"secret"
ppp[15708]: pppserv 1: raw bytes: 7e ff 03 c0 23 01 4b 00 15 08 "guest" 07
"secret" a3 "t~"
ppp[15708]: pppserv LCP1: Ack-Sent(8)->Opened(9)
ppp[15708]: pppserv: read 0xa bytes: proto=0xc023 02 4b 00 0a 05 "howdy"
ppp[15708]: pppserv PAP1: received Ack ID=0x4b containing "howdy"     {"howdy"
                                        means user name and passwd accepted}
ppp[15708]: pppserv 1: entering Network Phase
ppp[15708]: pppserv IPCP1: event Up
ppp[15708]: pppserv IPCP1: send Configure-Request ID=0xdb
ppp[15708]: pppserv IPCP1: request VJ comp, 16 slots without slot # comp
ppp[15708]: pppserv IPCP1: request ADDR 0.0.0.0   {asking for remote IP address}ppp[15708]: pppserv 1: write 0x10 bytes: proto=0x8021 01 . . .
ppp[15708]: pppserv 1: raw bytes: 7e . . .
ppp[15708]: pppserv IPCP1: Starting(1)->Req-Sent(6)
ppp[15708]: pppserv: read 0x10 bytes: proto=0x8021 01 . . .
ppp[15708]: pppserv IPCP1: received Configure-Request ID=0xd6
ppp[15708]: pppserv IPCP1: turn off slot number compression
ppp[15708]: pppserv IPCP1: accept VJ header compression with 16 slots
ppp[15708]: pppserv IPCP1: set its address to 192.0.2.2 from ADDR Request
                                                        {Remote IP given}
ppp[15708]: pppserv IPCP1: event RCR+
ppp[15708]: pppserv IPCP1: send Configure-ACK ID=0xd6
ppp[15708]: pppserv 1: write 0x10 bytes: proto=0x8021 02 . . .
ppp[15708]: pppserv 1: raw bytes: 7e . . .
ppp[15708]: pppserv IPCP1: Req-Sent(6)->Ack-Sent(8)
ppp[15708]: pppserv: read 0xa bytes: proto=0x8021 . . .
ppp[15708]: pppserv IPCP1: received Configure-NAK ID=0xdb
ppp[15708]: pppserv IPCP1: set our address to 192.0.2.3 from ADDR Nak
ppp[15708]: pppserv IPCP1: event RCN
ppp[15708]: pppserv IPCP1: send Configure-Request ID=0xdc
ppp[15708]: pppserv IPCP1: request VJ comp, 16 slots without slot # comp
ppp[15708]: pppserv IPCP1: request ADDR 192.0.2.3
ppp[15708]: pppserv 1: write 0x10 bytes: proto=0x8021 01 . . .
ppp[15708]: pppserv 1: raw bytes: 7e . . .
ppp[15708]: pppserv IPCP1: Ack-Sent(8)->Ack-Sent(8)
ppp[15708]: pppserv: read 0x10 bytes: proto=0x8021 . . .
ppp[15708]: pppserv IPCP1: event RCA
ppp[15708]: pppserv IPCP1: action TLU
ppp[15708]: pppserv IPCP1: Ack-Sent(8)->Opened(9)
ppp[15708]: pppserv IPCP1: ready 192.0.2.3 to 192.0.2.2, rx_vj_comp=y,tx=y
rx_compslot=n,tx=n rx_slots=16,tx=16
-------------------------------------------------------------------
Figure 4. A Successful PPP Session Negotiation

References

"Configuring and Debugging SLIP connections" Pipeline Volume 6, Number 4, July/August 1995

Additional information on selected SLIP (and PPP) topics is available on the World Wide Web using the URL (Uni form Resource Locator):

http://reality.sgi.com/employees/scotth/dialup_support.html.

Note that the information presented in this Web page is the responsibility of the individual author, and questions should be directed to him.

Information on PPP is available on the World Wide Web using the URL (Uniform Resource Locator):

http://cs.uni-bonn.de/ppp/faq.html#TOC

Note that the information presented in this Web page is the responsibility of the individual author, who has no connection to SGI in any way. It is provided only as a pointer to PPP-related reference information.

Chapters 5 and 3, "Slip and PPP" and "Setting up a Network" in the IRIX Admin: Networking and Mail Manual, chapter 1, "Terminals and Modems" in the IRIX Admin: Peripheral Devices, and PART TWO, "Security", in the IRIX Admin: Backup, Security, and Accounting Manual (available on-line with InSight)